what's wrong with std::auto_ptr<int> ptr(new int[100]) ?
Seems it works....?
what's wrong with std::auto_ptr<int> ptr(new int[100]) ?
Seems it works....?
The auto pointer destructor calls delete without brackets on the object it point's to. Delete without brackets can only be used on objects created by unbracketed new. An array is created with new[], and can only be deallocated by delete[]. Mismatching bracketed and unbracketed versions of new and delete is undefined behavior, and can result in crashes or memory leaks.
Even if it seems it works, doesn't mean it does, and even if it does, it's not portable.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
as King Mir said, that is not a correct use of auto_ptr. the functionality you want is provided by std::vector
"I saw a sign that said 'Drink Canada Dry', so I started"
-- Brendan Behan
Free Compiler: Visual C++ 2005 Express
If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?
Well for one, Compuware's DevPartner will bring up an error and tell you off.
It doesn't help the Microsoft header files have several such bugs. At least I came across several in the gdiplus headers recently.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Why didn't people implement auto_ptr with a "delete[]" in std::auto_ptr in the first place??? Since delete[] can be used for single pointer as well, for example:
delete[] works well here, doesn't it?Code:char * tmpi = new char; delete[] tmpi;
No - its undefined behaviour (Anything can happen). When memory is allocated with new, use delete, and when memory is allocated with new[], use delete[] - You can't mix and match these as you please.
Why exactly do you need an auto_ptr for a dynamically created array anyway? As someone else mentioned in this thread, you'd be better off using a std::vector
Last edited by Bench82; 07-10-2007 at 07:24 AM.
The UB comes from that delete without brackets doesnt call destructors on all of the array right? So would it be safe to use auto_ptr on primitive types since they dont have a destructor?
The memory s points to does get freed I'd say and no destructors need to be calledCode:char *s = new char[10]; delete s;
This exact same question was just asked somewhere recently. The answer was the same then.
>> So would it be safe to use auto_ptr on primitive types since they dont have a destructor?
No. It's undefined behavior. The fact that destructors aren't called is only a possible (or perhaps likely) symptom. Since you cannot guarantee what will happen, it is not safe to do that. In addition, since there are generally better alternatives, there's no reason to try.
The only case where somebody might prefer an auto_ptr for arrays is if they actually want to take advantage of the copy semantics where ownership is transferred rather than a copy being made. I'm not sure if there is a smart array class with these same semantics available, but I believe it will be easier to do that with vectors in C++0x.
auto_array would be rather trivial to write. Copy the auto_ptr source, replace delete with delete[] and add an index operator.
Yes, it will be easier in C++09:
Code:vector<int> other = std::move(source);
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law